CD ROM Paradise Collection 4

home *** CD-ROM | disk | FTP | other *** search

/ CD ROM Paradise Collection 4 / CD ROM Paradise Collection 4 1995 Nov.iso / graphics / gip_02.zip / GIP-SPEC.DOC < prev next >

Wrap

Text File | 1994-12-18 | 38KB | 835 lines

Graphic Interchange Protocol (GIP) Technical Standards -- Request For Comment Document #2 release .02 New stuff since .01 has a "│" as the first character of the line. The GIP specifications: the developer's viewpoint. OVERVIEW Most of this document is dedicated to the actual protocol used between the host and the terminal. However, there are 4 other major programming tasks involved: processing text/file for GIP codes, processing the input stream for GIP codes, actually doing the graphics, and working with objects. GIP.ASM is included to make the graphics part easy, and it should be used. The parsing jobs depend a lot on how you design your program, and/or how it normally handles I/O. GIP is just like ANSI and Avatar, just add a few extra code hooks to your I/O. Objects are a bit more confusing because they are kinda convoluted. Check out my code in ViewGIP, Commie, and Juggernaut for quicky answers. The protocol is only half the implementation of GIP. Right now, at least, the other half is being able to do the graphics in the same manner I do. Example: the protocol defines a box and provides two coordinates, but you must also put that box at the proper coordinates (use 0 to N - 1, not 1 to N, for example). The easiest way to test for this compatibility is using the .GIP sample files included here, or those from the Juggernaut files. COMMANDS h and v are coordinates. These go from 0 to N - 1 (N depends on the graphics mode). 0,0 is the upper-left corner of the screen. The numbers are integers (0, 1, 2, 3, etc.) "h" are the cordinates along the line (horizontal coordinates), and "v" are the vertical (up/down) coordinates. d is the depth for 3-D, and isn't coded for yet. The h,v,d values may either represent actual screen coordinates, or offsets from the last-used coordinate, command dependent. When they are offset values, negative numbers can be used. A "0" offset value means to draw at least one pixel--since you are drawing from the current pixel to pixel location + 0. n is a number, and its values are also command dependent. Within each command is text for developers. This contains the actual exchange specification information. A program that is to send GIP standard codes must convert the input stream to this format and send it. A program that is to receive GIP standard codes must convert the input stream from this to the various GIP actions. Also as part of the developers information section is what EACH SIDE is expected to do. For the most part, both the sending and receiving side do all things listed. The GIP codes (such as "S2;") are not sent (exchanged) between the BBS and comm program in the form which they are read in. The main difference being that the numbers are converted. So that instead of sending "123" as "1", "2", "3", we convert it to an integer and send the two-byte integer instead. This offers a slight throughput advantage, but also makes the code writing on the comm program's end much easier. Sending side: when you do things is up to you. Example: you can change to the color before sending the "Cn;" code, or after sending it. Notation: <x> when "x" is an ASCII number in byte (8 bit) form. [x] when "x" is a REAL number in integer (16 bit) form. {x} when "x" is something more complex. [[x]] when "x" is LONG number (32 bit). Variables you will need to maintain: color, pattern, currentH, currentV, currentD, objects, patternshift Examples: "Sn;" is exchanged as "<19><83><byte>" where "<byte>" contains the value of "n". "Mh,v,d;" is exchanged as "<19><77><int><int><int>" where the three "<int>"'s contain the values of "h", "v", and "d" in that order. Notice that the "" (ASCII 19) and the "S" and "M" are sent. Then the numbers are converted and sent. The comma's and semi-colons are not sent. The numbers are NOT sent as a series of ASCII characters, but converted to byte or 2-byte integer form and then sent as a byte or two bytes. The case of the "S" or "M" is significant. NOTE: For now, "d" is always 0. For the most part error checking need not be done (for example: if a box command orders a box outside valid range). Although DOS does handle these pretty well, the fact is that an MNP modem for error correction is pretty necessary when using this, and that if a sysop designs a menu that will fail then they need to correct it to have users using it. If the specs look like there is lots of oportunity for failure, that's because that's the way it was designed. Selected for speed rather than reliability. The logic: most people have MNP modems, and most sysops won't design GIP menus/text that cause their users to get stuck with a bad GIP code. This philosophy is continued in the lack of any way for a user to abort a GIP command in the middle (except through modem time-out). But if people really do have problems, or there is a need, I will re-write the specs to allow for more error-handling (although, frankly, the error handling would look very much like MNP which is why I didn't do it now). COMMAND DESCRIPTION Sn; Switch to graphics mode n. Where n is: 0 for standard 80x25 mode. 1 for 320x200x4 CGA (testing mode only). 2 for 640x480x16 VGA. 3 for 320x200x256 VGA. 4 for 640x480x256 SVGA. 5 for 800x600x256 SVGA. Example: S2; Begins graphic mode 2. S0; Returns back to normal (ANSI) mode. Modes 4 and 5 require an SVGA card, and are a bit less-automatic for beginner users. For general-audience graphics, you should stick with modes 2 and 3. Mode 2 provides for 80x60x16 text. While Mode 4 only provides for 40x25x256 text. For normal operations, mode 2 is the only real practical mode. It's drawback is that some sysops might find it's text a little small. This will be solved for in the future when I add support for more fonts. │ When this command is used, the current h,v,d positional values │ should be reset to 0. Thus, it can be interpreted as a standard │ clear-screen and go-to-top-of-screen order. Like ANSI's "[2J" or │ DOS's CLS. Similarly, you should set the color to Bright White │ (C15). Finally, the pattern should be reset to a solid line. │ GIP (ASCII 19) commands should be ignored unless already in │ graphics mode. So an Sn; command will precede all. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Sn;". │ │ IF n > 255 then don't process. │ │ Send "<19><83><n>". │ Receive "<19><83><n>". │ If the bbs/host system can │ If the system can handle the handle the screen mode, then │ screen mode, then change to change to that mode. │ that mode. │ Reset your line-pattern │ Reset your line-pattern variable to solid (-1 or 65534). │ variable to solid (-1 or 65534). Reset your pattern shift │ Reset your pattern shift variable to 0. │ variable to 0. EXAMPLE: "S2;" is sent (and received) as "<19><83><2>" (3 bytes). NOTE: We just change the line-pattern variable here, because there is nothing to draw/display. The drawing commands should have a parameter for line-pattern-to-use. If the mode cannot be handled, then use 0--it's safer then trying to squeeze higher resolution graphics into lower modes. Cn; Switch to color n. Where n is: 0 to 15 0 to 255 Example: C0; Change the current color to black. This depends on what mode you are in (either 16 or 256 colors). The 16 color mode follows the same color scheme as ANSI does. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Cn;". │ │ IF n > 255 then don't process. │ │ Send "<19><67><n>". │ Receive "<19><67><n>". │ Set your color variable to this │ Set your color variable to this value. │ value. EXAMPLE: "C64;" is sent (and received) as "<19><83><64>" (3 bytes). NOTE: DOS properly handles out-of-range values (eg. 16-255 in a 16 color mode) by "wrapping" to the first color and starting again the counter. We just change a variable here, because there is nothing to draw/display. The drawing commands should have a parameter for pixel color to use. Pn,s; Set the "pattern" to use for drawing lines and filling boxes. Where n is: 0 to 65534 -1 to 32767 A 16 character pattern of 0's and 1's (example: 0000111100001111). Where s is: -15 to 15 Example: P1,0; or P0000000000000001,0; will use " ∙" (15 blanks and then a dot) for the pattern for drawing lines, boxes, etc. The pattern is the same as formed by the ON/OFF bits of the number n, with an ON bit being a visible pixel, and an OFF bit being a skipped pixel. An exception is zero, this is changed to "-1" or "65534" and is equivalent to a solid line of pixels. I did this to make it easier to work with, and because "all pixels off" lines aren't likely to be needed. The default is a solid line, and this default is selected each time you change the screen mode. Otherwise the pattern defined stays in effect until you do a new pattern-change or another screen mode change. At the start of each line drawing order, we begin with the left- most pixel, and continue on through to the right. Starting again at the left after the 16th pixel. The exception to this is filled boxes. In order to avoid streaking lines, we incorpate "s"--the shift value. After each line when drawing a filled box, the bit pattern will be shifted according to s. A negative value means to rotate left, a positive value means to rotate right, a zero means no shifting. For example, for the "on-off-on-off" pattern, no shifting would yield not a pattern, but an organized set of vertical lines. If you shift more than one, you get organized slanted lines. So the shift you use depends on that pattern you use, and will probably require a little trial and error. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Pn,s;". │ │ If n = 0 then set n = -1. │ │ Send "<19><80>[n][s]". │ Receive "<19><80>[n][s]". │ │ If n = 0 then set n = -1. │ Set your pattern variable to │ Set your pattern variable to this n value. │ this n value. Set your shiftingvariable to │ Set your shifting variable to this s value. │ this s value. EXAMPLE: "P64,-1;" is sent (and received) as "<19><80>[64][-1]" (6 bytes). NOTE: We just change a variable here, because there is nothing to draw/display. The drawing commands should have a parameter for pattern to use. In a bit of "reverse logic" if the value of n is 0, you should use instead -1 or 65534--that is, a filled pattern for solid lines. The reasoning: a blank pattern won't be needed, so lets not confuse ourselves with -1 or 65534 and just use "P0,0;" to reset to solid lines. The pattern shifting value only needs to be used when drawing filled boxes--you do a bitshift in the specified direction after drawing each line. Gh,v,d; Go to point h,v,d. Example: G10,10,0; will move to graphics location 10,10. Nothing is displayed. h,v,d cannot be negative numbers. This is the most used command, as it's used to place lines, boxes, and text. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Gh,v,d;". │ │ IF h, v, or d, is < 0 then don't │ process. │ │ Send "<19><71>[h][v][d]". │ Receive "<19><71>[h][v][d]". │ Set your internal location-at │ Set your internal location-at variables to these three values. │ variables to these three values. EXAMPLE: "G100,200,0;" is sent (and received) as "<19><71>[100][200][0]" (8 bytes). NOTE: We just change variables here, because there is nothing to draw/display. The drawing commands should have parameters for h,v,d coordinates to start at. Mh,v,d; Go to offset point h,v,d. Example: G20,20,0; will move from the current location to offset 20,20. After the call, the new current location is 10,10 + the h,v offset (30,30). Nothing is displayed. This command is usually only used when defining objects, which by their nature can't be screen coordinate dependant. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Mh,v,d;". │ │ Send "<19><77>[h][v][d]". │ Receive "<19><77>[h][v][d]". │ Set your internal location-at │ Set your internal location-at variables by adding these values │ variables by adding these values to them. │ to them. EXAMPLE: "M100,-50,0;" is sent (and received) as "<19><77>[100][-50][0]" (8 bytes). NOTE: We just change variables here, because there is nothing to draw/display. The drawing commands should have parameters for h,v,d coordinates to start at. Lh,v,d; Draw a line from current point to h,v,d. Example: L20,20,0; will draw a line, in the current color, from the current location to offset 20,20. After the call, the new current location is 10,10 + the h,v offset. There is no "draw a point" command. To draw points, use very short lines. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Lh,v,d;". │ │ Send "<19><76>[h][v][d]". │ Receive "<19><76>[h][v][d]". │ Set your internal location-at │ Set your internal location-at variables by adding these values │ variables by adding these values to them. │ to them. │ Draw a line from your old │ Draw a line from your old location-at variables to your │ location-at variables to your new location-at variables using │ new location-at variables using your color variable and your │ your color variable and your pattern variable. │ pattern variable. EXAMPLE: "L100,-50,0;" is sent (and received) as "<19><76>[100][-50][0]" (8 bytes). Bh,v,d; Draw a rectangle from the current postition to h,v,d. Where h,v,d is the opposite corner of the rectangle. Example: B20,20,0; will draw a line-box, in the current color, from the current location to offset 20,20. After the call │ the current location is still 20,20,0. The current pattern is also used--since the box is usually drawn as four lines. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Bh,v,d;". │ │ Send "<19><66>[h][v][d]". │ Receive "<19><66>[h][v][d]". │ │ Draw a box from your current │ Draw a box from your current │ location-at variables to │ location-at variables to │ location-at + these values using │ location-at + these values using │ your color variable and your │ your color variable and your │ pattern variable. │ pattern variable. EXAMPLE: "B100,-50,0;" is sent (and received) as "<19><66>[100][-50][0]" (8 bytes). Fh,v,d; Draw a filled/solid rectangle from the current postition to corner h,v,d. Where h,v,d is the opposite corner of the rectangle. Example: F20,20,0; will draw a filled box, in the current color, from the current location to offset 20,20. After the call, │ the current location is still 20,20,0. The current pattern is also used. If you're trying to draw a box over text, and you get "ghosting" of the previous stuff in that area--that's a sure sign that you forgot to reset your pattern to solid--that "ghosting" is pixels being skipped due to the pattern. There is no hard rules on how to program for this. I use a hack of just drawing lines to form the box, and after each line rotating the bitmask of the pattern left 1 bit. This provides me with more of a dither look rather than the horizontal lines this method would usually generate. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "Fh,v,d;". │ │ Send "<19><70>[h][v][d]". │ Receive "<19><70>[h][v][d]". │ │ Draw a solid box from your │ Draw a solid box from your │ current location-at variables to │ current location-at variables to │ location-at + these values using │ location-at + these values using │ your color variable and your │ your color variable and your │ pattern variable. │ pattern variable. EXAMPLE: "F100,-50,0;" is sent (and received) as "<19><70>[100][-50][0]" (8 bytes). fPATHNAME; The file exchange protocol. The heart of GIP. It is used to send any files. Including .GIF's, .ICO's, .MOD's, .VOC's, etc. The software determines what to do with your file based on the file's extension. So if it's a GIF, use .GIF display, etc. Example: fC:\BBS\NCD.ICO; would display C:\BBS\NCD.ICO with it's upper-left corner starting at the current location. fC:\BBS\METAL.VOC; would play C:\BBS\METAL.VOC. It's really an "update protocol"--since the file will not be sent if the current version of the file already exists on the callers disk in his "your BBS identifier" directory. The path is not sent, only the filename. The current coordinates are not changed. In general, it works as such: Send Header with CRC. ACK receipt of header. If file is new/updated, then ENQ for a new file, else ACK that we already have it and it shouldn't be re-sent. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "fpathname;". │ │ IF pathname not found, then │ don't process. │ │ Send "<19><102>" │ Receive "<19><102>". │ Create variable x to contain: │ 8 bytes, the GIP ID. │ 12 bytes, the filename in │ "file.ext " form. │ 4 byte LONG, the file's size. │ 2 byte INTEGER, the file's │ time. │ 2 byte INTEGER, the file's │ date. │ │ Then we calculate a 16 bit CRC │ (xmodem/etc. standard) of x, call│ it c. │ │ Example: for "TESTER.ZIP 1,100,959 10:00:00 5/1/93", and the BBS's GIP ID is "STARCH", we send: "STARCH TESTER.ZIP [[size]][time][date]" 1. Send "{x}[c]" │ Receive "{x}[c]" │ Loop until receive "<5>" or │ If c is not the CRC of x, "<6>". │ then send "<5>" and goto 1. │ If receive "<5>" then goto 1. │ │ │ Send "<6>" and goto 2. │ If receive "<6>" then goto 2. │ │ NOTE: I designed my code to give up and exit after 5 tries or if the console had <esc> hit. Each try occuring if time-out or "resend" (ASCII 5) received. Time-out can be your choosing, 2-5 seconds probably best, but I use the fossil's own 30 second time-out. 2. Loop until receive "<5>" or │ Compare the file's name, date, "<6>". │ and size with what's on-line │ in directory "GIP ID". │ │ If match, send "<6>" goto 3. If receive "<6>" then goto 3. │ │ Send "<5>". │ Send "{x}" where x is the │ Receive the file's contents contents of the file. Only the │ into the specified filename in mere beginnings of a protocol │ the "GIP ID" directory. We here: We send 1024 byte blocks │ receive the file's size's worth followed by a delay in which we │ of bytes. This is done by wait for the other guy to send │ receiving 1024 bytes, writing a character. The final block │ it to a file, and then sending can be less than 1024 bytes. │ back a "<6>", and repeating. │ │ Give the file the time and date │ that we passed earlier. NOTE: Example: a file of size 2050 bytes: Sender: Receiver: send first 1024 bytes receive first 1024 bytes send "<6>" receive "<6>" send second 1024 bytes receive second 1024 bytes send "<6>" receive "<6>" send last 2 bytes receive last 2 bytes send "<6>" receive "<6>" The 1024 and waiting for ACK is done so we don't overflow │ buffers and lose characters. [might drop this in the │ future as unnecessary] 3. Display the file. │ Display the file. NOTE: "Display the file." for now merely means: "If extension is .ICO, then call up show icon routine and display this icon file." These are "standard" 766 byte sized 16-color icon files. Thus, for now only .ICO files are supported. More graphic formats will be added in the future. Any other format should be displayed as a normal text/ansi file of any size. Except for .BMP--the trouble is that right now the only BMP displayer I has displays the colors slightly off. On;~xxx~ Define an object for later display. Where n is: 0 to 255 Example: O1;~C3;G5,5,0;L15,5,0;L15,15,0;L5,15,0;L5,5,0;~ Which defines Object #1 to be orders to: change to color 3 and goto 5,5 and draw a box. It's very flexible, you can have GIP codes and normal text intermixed. It's not displayed at the time you define/send it. Only three restrictions: no GIP "f<pathname>" commands nor other object commands (either defining or using) should be inside the two "~" characters. And, of course, no "~" allowed inside the definition. This is the cyberspace command, with which we will have cyberspace in the future. When defining objects, the maximum size of any one object is 2048 bytes, and the size of all objects must not exceed 8192 bytes. If you need to exceed these limits, I recommend using either an icon or graphic image file. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "On;~xxx~". │ │ IF n > 255 then don't process. │ │ Store "xxx" in objects-variable │ number n. │ │ Send "<19><79>[n][z]xxx". │ Receive "<19><79>[n][z]". Where z is the length of "xxx". │ │ IF n > 255 then don't process. │ │ Receive "xxx" for length z. │ │ Store "xxx" in objects-variable │ number n. EXAMPLE: "O64;~hi there~" is sent (and received) as "<19><79>[64][8]hi there" (14 bytes). NOTE: Nothing is shown/displayed. If there are GIP codes in the "xxx" then these are not converted to anything (just yet). Thus "C2;HiC3;there" stays in this form when stored to the object variable. on; Call up and display/use an Object. Where n is: 0 to 255 Example: o1; Will display Object #1 we defined earlier. This offers fast graphics, since the commands do not have to be re-sent each time you want to display the same thing. It also offers the sysop convience. When testing postioning of GIP drawings, and when working with lots of the same drawings. BBS/HOST PROGRAM │ TERMINAL/COMMUNCATIONS PROGRAM │ Obtain "on;". │ │ IF n > 255 then don't process. │ │ Send "<19><111><n>". │ Receive "<19><111><n>". │ │ IF n > 255 then don't process. │ Process the data stored in │ Process the data stored in object n's variable. │ object n's variable. For GIP codes, we convert and │ For GIP codes, we need a minor process as normal, but don't │ BBS-like parser to convert them send them out the port. │ to usable form. EXAMPLE: "o2;" is sent (and received) as "<19><111><2>" (3 bytes). NOTE: Processing GIP codes from Terminal side is not as hard as it may first seem (see example source code). ASCII TEXT Text is like lines--its pixels are drawn on top of whatever is there already. It uses whatever was the last defined color, at whatever was the last location. For now, only an 8x8 font is used. After each character is displayed, we automatically add 8 to the orginal (pre-drawing) horizontal location, which has the effect of putting us right where the next character would be drawn. For spans of spaces, 8 or fewer spaces is more efficient than using a "Gh,v,d;" command to move you ahead. For CR/LF's, we simply change the horizontal coordinate to zero, and add 8 to the vertical coordinate. This allows us to display normal text going down the screen normally. However, there are problems when you reach the end of the screen--as the there no scrolling in GIP (nor any wraparound to the next lines). Think of CR/LF's this way: just another cursor positioning command: "go to start of next line". Usually the effects of CR/LF's do not matter. They are very useful for making GIP files readable. So don't be afraid to use them for that purpose. The full 256 character ASCII set may be sent and displayed except for the following codes: 10, 13, 19, 12, 22, 25, 27 These codes are used by ANSI, GIP, Avatar, and text to signify something besides their normal ASCII character. EXAMPLES "S2;fC:\BBS\NODE001\GRA\PIC1.ICO;G300,300,0;Hi there!" will: clear the screen and go to graphics mode (S2;) send the file PIC1.ICO (if the caller doesn't have it already) (fC:\BBS\NODE001\GRA\PIC1.ICO;) locate pixel 300,300 (G300,300,0;) and display "Hi there!" at that point (normal ASCII text) "S2;G300,300,0;fC:\BBS\NODE001\GRA\PIC1.ICO;Hi there!" will: same as the above, but draws the icon at 300,300 and "Hi there!" right after the icon. NOTES GIP codes, like ANSI, can be put into files and displayed. I recommend the extension .GIP (like .ANS) but it's not required. GIP contains no error-checking stuff, and so should only be used by MNP modems (the baud doesn't matter). Before shelling to dos (or exiting the program) you should reset the graphics mode to normal 80x25 ANSI. CONVERTING TEXT FILES TO GIP For bare bones conversion of a standard text file to gip, there are only two things to do: Add a "Sn;Cn;" at the start of the file. Add a "S0;" at the end of the file. CONVERTING ANSI FILES TO GIP These are the steps to follow that to make conversi of ANSI's easier: First, convert the "[xC" "cursor jumping" commands to their spaces equivalent. Example "[7C" becomes " ". You can optimize it with "Gh,v,d;" commands later. A "Gh,v,d;" command uses 8 characters in it's transmission, so there is nothing to be gained by reducing gaps 8 or fewer characters to "Gh,v,d;" calls. Second, convert the "[x,y,zm" color commands. Easy except for background commands "[44m"--in which case you'll probably want to first draw a filled box of the length desired and then draw the characters on top of it. The above stuff on converting normal text files is useful too. 0,8,16,24 etc. correspond to normal 80x25 text columns. VIEWGIP Also enclosed is VIEWGIP.EXE. ViewGIP will let you display files with GIP codes inside them. It works much like TYPE filename.ANS works. Just type: VIEWGIP filename.GIP The only limitations are that the two SVGA modes won't work with this viewer, and the maximum file size is 16k. The program will display the file, and then wait for you to hit a key. For best viewing, I recommend you remove any "S0;" mode-to-normal you have at the end of the file before displaying. The source code for ViewGIP is VIEWGIP.BAS. Like all the included source code, it both uses the GIP.ASM graphic routines, and makes use of some of my assembly routines from Juggernaut (not included). COMMIE Commie is available in a separate archive. Your users can use this program to see your GIP graphics. The source code to Commie is COMMIE.BAS. For those interested in adding GIP ability to their communications program, this will be invaluable. For those interested in adding it to BBS programs, you should get the Juggernaut program and take a look at it. CONCLUSION All of the above stuff is already coded and done. The only supported file │ display format right now is ".ICO" for icons, and .BMP for images--and I'm │ looking for source code to display ANY other graphic formats. The stuff below still needs to be done, and will be available sometime in the future: d coordinates (depth/3-D stuff) GIFs/TIFs/PCXs/BMPs sound files (VOC/MOD) fonts (TrueType preferred) circle's/elipses etc. This is a very open-ended standard. It's success and power depend on other people supplying code for many of the things not done. For instance, I don't know 3-D graphics programming, the drivers for sound cards, or how to display the various image file formats. I'll teach myself and get it, but reinventing wheels is not efficient. So feel free to help. I can be reached for comment/suggestions at: Immortality 414-643-1576 24 hrs. Either log in, or just dump your NetMail on me. John Rohner January 1994 I hereby release the GIP specifications, and any code specific only to implementing the GIP specifications I include as an example, to the Public Domain for full, free, and uncredited distribution by other GIP-capable program authors. With the premediated hope that authors will simply import the code into their program to provide GIP support. With a promise to never challenge nor discredit said authors, and that this Public Domain declaration shall be eternal. This declaration does not extend to the various subroutines used to form the example programs in which the GIP subroutines reside.